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Abstract 

Li and Zdancewic have recently proposed an approach 
to provide information-flow security via a library rather 
than producing a new language from the scratch. They 
have shown how to implement such a library in Haskell by 
using arrow combinators. However, their approach only 
works with computations that have no side-effects. In fact, 
they leave as an open question how their library, and the 
mechanisms in it, need to be modified to consider these 
kind of effects. Another absent feature in the library is sup- 
port for multithreaded programs. Information- flow in mul- 
tithreaded programs still remains as a challenge, and no 
support for that has been implemented yet. It is not surpris- 
ing, then, that the two main stream compilers that provide 
information-flow security, Jif and FlowCaml, lack support 
for multithreading. 

Following ideas taken from literature, this paper presents 
an extension to Li and Zdancewic' s library that provides 
information-flow security in presence of reference manipu- 
lation and multithreaded programs. Moreover, an online- 
shopping case study has been implemented to evaluate the 
proposed techniques. The case study reveals that exploit- 
ing concurrency to leak secrets is feasible and dangerous 
in practice and how our extension helps avoiding that. To 
the best of our knowledge, this is the first implemented tool 
to guarantee information-flow security in concurrent pro- 
grams and the first implementation of a case study that in- 
volves concurrency and information-flow policies. 



1 Introduction 

Language-based information flow security aims to guar- 
antee that programs do not leak confidential data. It is com- 
monly achieved by some form of static analysis which re- 
jects programs that would leak, before they are run. Over 
the years, a great many such systems have been presented, 
supporting a wide variety of programming constructs [25]. 
However, the impact on programming practice has been 



rather limited. 

One possible reason is that most systems are presented in 
the context of a simple, elegant, and minimal language, with 
a well-defined semantics to make proofs of soundness pos- 
sible. Yet such systems cannot immediately be adopted by 
programmers — they must first be embedded in a real pro- 
gramming language with a real compiler, which is a ma- 
jor task in its own right. Only two such languages have 
been developed — Jif [13,14] (based on Java) and FlowCaml 
[18,29] (based on Caml). 

Yet when a system implementor chooses a program- 
ming language, information flow security is only one fac- 
tor among many. While Jif or FlowCaml might offer the 
desired security guarantees, they may be unsuitable for 
other reasons, and thus not adopted. This motivated Li and 
Zdancewic to propose an alternative approach, whereby in- 
formation flow security is provided via a library in an ex- 
isting programming language [12]. Constructing such a li- 
brary is a much simpler task than designing and implement- 
ing a new programming language, and moreover leaves sys- 
tem implementors free to choose any language for which 
such a library exists. 

Li and Zdancewic showed how to construct such a li- 
brary for the functional programming language Haskell. 
The library provides an abstract type of secure programs, 
which are composed from underlying Haskell functions us- 
ing operators that impose information-flow constraints. Se- 
cure programs are certified, by checking that all constraints 
are satisfied, before the underlying functions are invoked — 
thus guaranteeing that no secret information leaks. While 
secure programs are a little more awkward to write than 
ordinary Haskell functions, Li and Zdancewic argue that 
typically only a small part of a system needs manipulate 
secret data — for example, an authentication module — and 
only this part needs be programmed using their library. 

However, Li and Zdancewic's library does impose quite 
severe restrictions on what a secure program fragment may 
do. In particular, these fragments may have no effects of any 
sort, since the library only tracks information flow through 
the inputs and outputs of each fragment. While absence of 
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Figure 1. Basic arrow combinators. 



side-effects can be guaranteed in Haskell (via the type sys- 
tem), this is still a strong restriction. Our purpose in this 
paper is to show that the same idea can be applied to sup- 
port secure programs with a much richer set of effects — 
namely updateable references in the presence of (cooper- 
ative) concurrency. The underlying methods we use — an 
information-flow type-system for references, a restriction 
on the scheduler — are taken from the literature; what we 
show here is how to implement them for a real program- 
ming language following Li and Zdancewic's approach. 

The rest of this paper is structured as follows. In the 
next section we explain Li and Zdancewic's approach in 
more detail. One restriction of their approach is that data- 
structures are assigned a single security level — so if any part 
of the output of a secure program is secret, then the entire 
output must be classified as secret. We need to lift this re- 
striction in our work, allowing data-structures with mixed 
security levels, and in Section 3 we show how this can be 
achieved. This enables us to add references in Section 4. 
We then introduce concurrency, reviewing approaches to se- 
cure information flow in this context in Section 5, in partic- 
ular ways to close the internal timing covert channel, and 
in Section 6 we describe the implementation of our chosen 
approach. In Section 7 we present a concurrent case study 
involving online shopping. With no countermeasures, an at- 
tack based on internal timing leaks can obtain a credit-card 
number with high probability in about two minutes. We 
show that our library successfully defends systems against 
this kind of attack. Finally, in Section 8, we draw our con- 
clusions. 

2 Encoding Information Flow in Haskell 

Li and Zdancewic's approach represents secure program 
fragments as arrows in Haskell [8]. Arrows can be visu- 
alised as dataflow networks, mapping inputs on the left to 




Figure 2. Average of a list. 
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Figure 3. Choice between f and g. 



outputs on the right. Arrows are constructed from Haskell 
functions using combinators, of which the most important 
are illustrated in Figure 1 — pure converts a Haskell func- 
tion to an arrow, ( > > > ) sequences two arrows, and ( * * * ) 
pairs arrows together. Any required left-to-right static 
dataflow can be implemented using these combinators — for 
example, an arrow that computes the average of a list could 
be constructed as 

squareA = pure tee >>> 

(pure sum *** pure length) >>> 
pure divide 
where tee x = (x,x) 

divide (x,y) = x/y 

Its effect is illustrated in Figure 2. To express a dynamic 
choice between two arrows, there is an additional combina- 
tor f | | | g, whose input is of Haskell's sum type: 

data Either a b = Left a I Right b 

Its effect is illustrated in Figure 3. 

Haskell allows any suitable type to be declared to be an 
arrow, by providing implementations for the basic arrow 
combinators. This is usually used to encapsulate some kind 
of effects. For example, we might define an arrow for pro- 
gramming with references, by declaring ArrowRef a b 
to be the type of arrows from a to b, implementing the basic 
combinators, and then providing arrows 

createRefA : : ArrowRef a (Ref a) 
readRefA : : ArrowRef (Ref a) a 
writeRefA :: ArrowRef (Ref a, a) () 

to perform the basic operations on references. With these 
definitions, we can write side-effecting programs in a 
dataflow style. For example, an arrow to increment the con- 
tents of a reference could be programmed as 

incrRefA :: ArrowRef (Ref Int) () 
incrRefA = 
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Figure 4. Typing rules for pure and >>>. 

(pure id &&& (readRefA >>> pure (+1))) 
>>> writeRefA 

where f &&& g = pure tee >>> (f***g) 

Li and Zdancewic found another use for arrows: they 
realised that, since all the data- and control-flow in an ar- 
row program is expressed using the arrow combinators, then 
they could define a type of flow arrows, whose primitive 
arrow combinators implement the type checking of an in- 
formation flow type system. Their type system assigns a 
security label drawn from a suitable lattice, such as 

data Label = LOW | MEDIUM | HIGH 
deriving (Eq, Ord) 

to the input and output of each arrow (where the 
deriving clause declares that LOW<MEDIUM<HIGH). 
Their arrows themselves are represented by the type 
FlowArrow 1 arr a b, which is actually an arrow 
transformer, the type 1 is the security lattice, a and b are 
the input and output types, and arr is an underlying arrow 
type such as ArrowRef . Flow arrows contain arrows of 
type arr a b, together with flow information about their 
inputs and outputs. 

In the information flow type system, an arrow is assigned 
a flow type l\ — > £ 2 under a set of constraints, where i\ and 
I2 are security labels. The rules for pure and (>>>) are 
given in Figure 4. The FlowArrow type represents not 
only the underlying computation, but also the information 
flow typing — it is represented as a record 

data FlowArrow 1 arr a b = FA 
{ computation : : arr a b, 
flow : : Flow 1 , 

constraints :: [Constraint 1] 

} 

data Flow 1 = Trans 1 1 I Flat 
data Constraint 1 = LEQ 1 1 

Here the flow component represents either l\ — > £2 
(Trans 11 12), or the "polymorphic" I — > I for any 
I (Flat), which is needed to give an accurate typing for 
pure. The constraints field just collects the con- 
straints on the left of the turnstile. With this representation, 
it is easy to implement the typing rules in the arrow com- 
binators. Security labels are introduced and checked by the 
arrow tag 1, with flow Trans 1 1, which forces both 
its input and output to have the given security label. 

Note that the information flow types are quite indepen- 
dent of the Haskell types! Moreover, they are not checked 
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Figure 5. Extended security types 
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Figure 6. Subtyping relationship 

during Haskell type-checking. Rather, when a flow ar- 
row is constructed during program execution, all the nec- 
essary constraints are collected dynamically — but they are 
checked before the underlying computation is run. Li and 
Zdancewic's library exports FlowArrow as an abstract 
type, and the only way to extract the underlying compu- 
tation is via a certification function which solves the con- 
straints first. If any constraint is not satisfied, then the un- 
derlying code is rejected. 

Li and Zdancewic also considered declassification, 
which requires adding the user's security level as a context 
to the typing rules, and a new form of constraint — but we 
ignore the details here. 

3 Refining Security Types 

Li and Zdancewic's library uses single security labels as 
security types. As a consequence, values are classified se- 
crets when they contain, partially or totally, some confiden- 
tial information. For instance, if one component of a pair 
is secret, the whole pair becomes confidential. This design 
decision might be a potential restriction to build some ap- 
plications in practice. With this in mind, we extend Li and 
Zdancewic's work to include security types with more than 
one security label. The presence of several security labels in 
security types allows to develop a more precise, and conse- 
quently permissive, analysis of the information flow inside 
of a program. 

3.1 Security Types 

We assume a given security lattice L where security lev- 
els, denoted by £, are ordered by a partial order <. Top and 
bottom elements are written T and _L, respectively. Secu- 
rity types are given in Figure 5 and their subtyping relation- 
ship in Figure 6. Security type (s L , s L ) provides security 
annotations for pair types. Security type (either s L s L ) l 
provides annotations for type Either. Security type t dec- 
orates any other Haskell type (e.g. Int, Float, [a], etc.). 
Security types are represented in our library as follows: 
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data SecType 1 

= SecLabel 1 

I SecPair (SecType 1) (SecType 1) 

I SecEither (SecType 1) (SecType 1) 1 

where 1 implements a lattice of security levels. 

3.2 Defining FlowArrowRef 

The abstract data type FlowArrowRef defines our em- 
bedded language by implementing an arrow interface: 

data FlowArrowRef 1 a b c = FARef 

{ computation : : a b c 

, flow : : Flow (SecType 1) 

, constraints :: [Constraint (SecType 1)] } 

This definition is similar to the definition of FlowArrow 
except for using (SecType 1) as type argument for 
Flow and Constraint. Constructor Flat needs to be 
removed from data type Flow as a consequence of deal- 
ing with security types with more than one security la- 
bel. In FlowArrow, Flat is used to establish that pure 
computations have the same input and output security type. 
Unfortunately, Flat cannot be used in FlowArrowRef, 
otherwise secrets might be leaked. For instance, consider 
the program pure ( (x,y) -> (y,x) ) that just 
flips components in a pair. Assume that x, annotated with 
security label HIGH, is a secret input and y, annotated 
with security label LOW, contains public information. If 
( H I GH , LOW ) is the input and output security types for that 
program, the value of x will be immediately revealed! 

Similarly to Li andZdancewic's work, FlowArrowRef 
encodes a typing judgement to verify information-flow poli- 
cies. Naturally, our encoding is more complex than that 
in FlowArrow. This complexity essentially arises from 
considering richer security types. The typing judgment has 
the form: C h / : t\ \ s\ — > T2 | s^, where / is 
a purely-functional computation, C is a set of constrains 
that, when satisfied, guarantees information-flow policies, 
and n | s\ — > T2 | s\ is a flow type, which denotes 
that / receives input values of type n with security type s\ , 
and produces output values of type r 2 with security type s\ . 
Except for combinator pure, most of the typing rules in 
Li and Zdancewic's work can be easily rewritten using this 
typing judgment, and therefore, we omit them here. 

3.3 Security Types and Combinator pure 

Different from Li and Zdancewick's work, it is not 
straightforward to determine security types for computa- 
tions built with arrow combinators. Basically, the diffi- 
culty comes from deciding the output security type for 
combinator pure. This combinator can take any arbitrary 
Haskell function as its argument. Then, the structure of its 
output, and consequently its output security type, can be 
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Figure 7. Typing rule for combinator pure 

different in every application. For instance, output secu- 
rity types for pure computations that return numbers and 
pair of numbers consist of security labels and pair of se- 
curity labels, respectively. Moreover, although the struc- 
ture of the output security type could be determined, it is 
also difficult to establish the security labels appearing in it. 
To illustrate this point, consider the computation pure ( 
\ (x,y) -> (x+y, y) ), where inputs x and y have 
security labels LOW and HIGH, respectively. It is clear that 
the output security type for this example is (HIGH, HIGH). 
However, in order to determine that, it is necessary to know 
how the input is used to build the output. This input-output 
dependency might be difficult to track when more complex 
functions are considered. With this in mind, we introduce a 
new security type to s L : 

s L ::= I | (s L , s L ) | (either s L s L f | only i 

Security type only t represents any security type that 
contains all their security labels as I. Typing rule for pure 
is given in Figure 7. Observe the use of the Haskell typing 
judgment (written ::) in the hypothesis of the rule. Func- 
tion join(s\) computes the join of all the security labels 
in s^. Essentially, the typing rule over-approximates the 
output security type by using the security labels found in 
the input security type. By only having one piece of se- 
cret information as input, results of pure computations are 
thus confidential regardless what they do or what kind of 
result they return. As a consequence, computations that fol- 
low combinator pure cannot operate on public data any 
more. As an example, consider the program f >>> pure 
( \(x,y) -> y + 1) >>> g, where computation g 
operates on public data and computation f produces a pair 
where the first and second components are secret and public 
values, respectively. This simple program just adds one to 
the public output of f and provides that as the input of g. 
However, the program is rejected by the encoded type sys- 
tem in our library, even though no leaks are produced by this 
code. The reason for this is that program g receives confi- 
dential information from pure while it expects only public 
inputs. Since pure is responsible for allowing the use of 
any Haskell functions in the library, this restriction seems 
to be quite severe to implement concrete applications. 

3.4 Combinator lowerA 

Combinator lowerA is introduced to mitigate the re- 
striction of not allowing computations on public data to 
take some input produced by pure combinators. Basically, 
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lower A takes a security label i and an arrow computation 
p, and returns a computation p'. Computation p' behaves 
like p and has the same input type, output type, and input 
security type as p. However, its output security type might 
be different. The output security type is constructed based 
on the output type of p and it contains only security labels 
of value I. In other words, lower A downgrades the out- 
put of p to the security level I. In principle, this combina- 
tor might be also used to leak secrets. An attacker can just 
apply (lowerA LOW) to every computation that involves 
secrets! To avoid this kind of attacks, lowerA filters out 
data with security level higher than I. 

Input Filtering Mechanism 

Filtration of data is done by replacing some pieces of 
information with undefined This idea is imple- 
mented by the function removeData of the type-class 
FilterData. The signature of the type-class is the fol- 
lowing: 

class (Lattice 1) => FilterData 1 t where 
removeData : : 1 -> t -> (SecType 1) -> t 

Method removeData receives a security level 1, a 
value of type t, and a security type (SecType 1), 
and produces another value of type t where the infor- 
mation with security label higher than 1 is replaced by 
undefined. As an example, instantiations for integers 
and pairs are given in Figure 8. Observe how the use of 
type-classes allows to define different filtering policies for 
different kind of data. This is particularly useful when ref- 
erences are introduced in the language (see Section 4.6). 

The introduction of undefined values might also intro- 
duce leaks due to termination. For instance, if filtered val- 
ues are used inside of computations that branches on se- 
crets, then the program might terminate (or not) depending 
on which branch is executed. However, these kind of leaks 
only reveal one bit of information about confidential data. 
In some scenarios, leaking one bit due to termination is ac- 
ceptable and termination-insensitive security conditions are 
adopted for those cases. In fact, our library is particularly 
suitable to guarantee termination-insensitive security spec- 
ifications. 

Building Output Security Types 

Besides introducing a filtering mechanism, lowerA 
constructs output security types where security labels are 
all the same. We define the following type-class: 

class (Lattice 1) => BuildSecType 1 t where 
buildSecType : : 1 -> t -> (SecType 1) 

'This is an undefined value in Haskell and it is member of every type. 



instance (Lattice 1) 

=> FilterData 1 Int where 

removeData 1 x (SecLabel 1' ) = 
if label_leq 1' 1 then x 
else undefined 
instance (Lattice 1, FilterData 1 a, 
FilterData 1 b) 
=> FilterData 1 (a,b) where 
removeData 1 (x, y) (SecPair lx ly) = 
(removeData 1 x lx, removeData 1 y ly) 

Figure 8. Instantiations for FilterData 

instance (Lattice 1) => 

BuildSecType 1 Int where 
buildSecType 1 _ = (SecLabel 1) 

instance 

(Lattice 1, BuildSecType 1 a, BuildSecType 1 b) 
=> BuildSecType 1 (a,b) where 
buildSecType 1 _ = 

(SecPair (buildSecType 1 (undef ined : : a) ) 
(buildSecType 1 (undef ined :: b) ) ) 

Figure 9. Instantiations for BuildSecType 

Method buildSecType receives a security label 1 and 
a value of type t, and produces a security type for t where 
security labels are 1. For instance, it produces security type 
(1,1) for pair of integers. Instantiations for pairs and in- 
tegers are given in Figure 9. Observe that the value of the 
second argument of buildSecType is not needed, but its 
type. Type-classes provide a mechanism to access informa- 
tion about types in Haskell and take different actions, like 
building different security types, depending on them. 

When lowerA receives a computation as an argument, 
it needs to know its output type in order to properly apply 
buildSecType. For that purpose, we introduce another 
type-class: 

class (Lattice 1, Arrow a) 

=> TakeOutputType 1 a b c where 

deriveSecType : : 1 -> (a b c) -> (SecType 1) 

Method deriveSecType receives a security label 1, an 
arrow computation (a b c ) , and returns the correspond- 
ing security type (SecType 1 ) for the output type c. The 
instantiation of this type-class is shown in Figure 10. 

To put it briefly, combinator lowerA creates a new 
computation that behaves as the computation received 
as argument, but calling the methods removeData and 
buildSecType in due course. The type signature for 
lowerA is given in Figure 11. Typing rule for lowerA 
is shown in Figure 12. Observe how the output security 
type is changed. Function p is defined in Figure 13 and 
implemented by the method buildSecType. As a sim- 
ple example of the use of lowerA, we rewrite the example 



5 



instance 

(Lattice 1, BuildSecType 1 c, Arrow a) 
=> TakeOutputType 1 a b c where 
deriveSecType 1 ar = 

buildSecType 1 (undef ined : : c) 

Figure 10. Instantiation for TakeOutputType 

lowerA : : ( Lattice 1, Arrow a, 

FilterData 1 b, BuildSecType 1 c, 
TakeOutputType 1 
(FlowArrowRef 1 a) b c ) 
=> 1 -> FlowArrowRef 1 a b c -> 
FlowArrowRef 1 a b c 

Figure 1 1 . Type signature for lowerA 

in Section 3.3 as follows: f >>> lowerA LOW (pure 
(\(x,y) -> y + 1)) >>> g. Observe that the value 
received by program g is not confidential anymore, and 
consequently, the program passes the type-checking tests 
in our library. In this example, the filtering mechanism of 
lowerA does not introduce leaks due to termination. In 
general, the possibilities to exploit undefined values intro- 
duced by computations like 1 owe r A LOW p are related to 
the security of p. If p only produces LOW values, no leaks 
due to termination are introduced. Otherwise, if p presents, 
for instance, some flows from secret data to its output, a 
one-bit leak due to termination might happen as a price to 
pay for not being able to predict the input-output depen- 
dency of p and avoiding leaking the whole secret. 

One alternative implementation to the input filter mech- 
anism in lowerA I p could have been to reject compu- 
tation p if it takes some input with security label higher 
than I. Unfortunately, this idea might not work properly 
when programs take input from external modules or com- 
ponents, which frequently provide data with different secu- 
rity levels to arrow computations. Consequently, the pattern 
lowerA i (pure /) is particularly useful to get any values 
at security levels below £ regardless the security input type 
of pure /. 

4 Adding References 

Dealing with information-flow security in languages 
with reference manipulation is not a novelty. Unsurpris- 
ingly, Jif and FlowCaml include them as a language fea- 
ture. Nevertheless, it is stated as an open question how Li 
and Zdancewic's library needs to be modified to consider 
side-effects. In particular, what arrows could be used to 
handle them and how their encoded type system needs to 
be modified. We have already started answering these ques- 
tion with the modification of pure and the introduction of 
lowerA in Section 3. We will complete answering Li and 
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Figure 12. Typing rule for lowerA 
p(int,£) -> £ 

p(rref,£) -► s\ ref £ 
pjnj.) -> s\ p(T 2 ,£) -> f| 

p((n,r 2 ),£) - (s\,s\) 
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p(either ti t 2 ,£) — > (either s\ s\) 1 

Figure 13. Definition for Function p 

Zdancewic's questions by showing how to extend their li- 
brary to introduce references. The developed techniques in 
this section can be considered for other kind of side-effects 
as well. 

4.1 Security Types for References 

The treatment of references is based on Pottier and Si- 
monet's work [18]. They introduce security types for ref- 
erences containing two parts: a security type and a security 
label. The security type provides information about the data 
that is referred to, while the security label gives a security 
level to the reference itself as a value. Following the same 
approach, we extend our security types as follows: 

s L ::= £ | (s\ s L ) | (either s L s L f | only £ | s L ref" 

Observe that security types for references (s L ref £ ) are 
composed of two parts as mentioned before. The subtyping 
relationship is also extended as follows: 

s\ = s | 4C £ 2 

- (1) 

s\ ref 1 C 4 ref* 2 

In order to avoid aliasing problems [15], this rule imposes 
an invariant in the subtyping relationship by requiring s\ 
to be the same as s 2 . Clearly, this invariant needs to be 
preserved by the arrow combinators in the library. How- 
ever, lowerA could break that invariant! Remember that it 
changes every security label in the output security type of a 
given computation. As a consequence, we need to modify 
its implementation (see Section 4.2). 

Data type SecType is extended as follows: 

data SecType 1 

= SecLabel 1 

SecPair (SecType 1) (SecType 1) 
SecEither (SecType 1) (SecType 1) 1 
SecRef (SecType 1) 1 
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where SecRef (SecType 1) 1 represents security 
types for references. 

4.2 References and Combinator lowerA 

Combinator lowerA could break the subtyping invari- 
ant for references described in (1). As a result, aliasing 
problems, and therefore leakage of secrets, might be intro- 
duced. The root of this problem comes from the fact that 
lowerA only uses output types to determine output secu- 
rity types. To illustrate this problem, consider a program 
that has two public references, rl and r2, with security 
type (SecRef (SecLabel LOW) LOW) . Assume that 
both references refer to the same value. If rl, for instance, 
is fed into the computation lowerA HIGH (pure id), 
the output produced, which is obviously rl, will have secu- 
rity type (SecRef (SecLabel HIGH) HIGH) . Ob- 
serve that the security type for the content of the reference 
has changed. After doing that, leaks can occur by writing 
secrets using rl and reading them out by using r2. Nat- 
urally, lowerA could also examine input security types, 
but unfortunately this is not enough. Once again, the dif- 
ficulty to track input-output dependencies of pure com- 
putations (see Section 3.3) makes it difficult to determine, 
for instance, which reference from the input correspond to 
which reference in the output. Consequently, it is also diffi- 
cult to determine security types for references in the output 
based on the input security types. To overcome this prob- 
lem, we use a mechanism that can transport security infor- 
mation about contents of references from the input to the 
output of an arrow computation. In this way, lowerA can 
read this information and place the corresponding security 
types references when needed, and thus keep the subtyping 
invariant. This mechanism relies on the use of singleton 
types, which are the topic of the next section. 

4.3 Preserving Subtyping Invariants 

On one side, combinator lowerA builds output secu- 
rity types based on the output type of computations. On 
the other hand, security types for the content of references 
must never be changed. So, why not encoding in the Haskell 
type system the security type for the content of references? 
Hence, lowerA can take the encoded information and pre- 
cisely determines the corresponding security type for the 
content of each reference. 

Singleton types [16] are adequate to represent specific 
values at the level of types. Essentially, they allow to have a 
match between values and types and vice versa. Our goal is, 
therefore, to encode values of type (SecType 1) in more 
fine-grained Haskell types. For instance, the encoding for 
values of type (SecType Label) can be done as fol- 
lows: 



data SLow = VLow 
data SMedium = VMedium 
data SHigh = VHigh 

data SSecLabel lb = VSecLabel lb 

data SSecPair stl st2 = VSecPair stl st2 
data SSecEither stl st2 lb= VSecEither stl st2 lb 
data SSecRef st lb = VSecRef st lb 

Observe how one type has been introduced for each con- 
structor appearing in Label and SecType. With this en- 
coding, we can now represent security types in the Haskell 
type system. As an example, security type (SecRef 
(SecLabel HIGH) LOW) can be encoded using the 
value (VSecRef (VSecLabel VHigh) VLow) of 
type (SSecRef (SSecLabel SHigh) SLow). 

As mentioned before, lowerA should use the encoded 
information to place the corresponding security types for 
content of references. In order to achieve that, we need a 
mapping from singleton types to values of type ( SecType 
1 ) . The following code implements that: 

class STLabel lb 1 where 
toLabel : : lb -> 1 

instance STLabel SLow Label where 

toLabel _ = LOW 
instance STLabel SMedium Label where 

toLabel _ = MEDIUM 
instance STLabel SHigh Label where 

toLabel _ = HIGH 

class STSecType st 1 where 

toSecType : : st -> SecType 1 

instance STLabel lb 1 

=> STSecType (SSecLabel lb) 1 where 
toSecType _ 

= SecLabel (toLabel (undef ined : : lb) ) 
instance (STSecType st 1, STLabel lb 1) 
=> STSecType (SSecRef st lb) 1 where 
toSecType _ 

= SecRef (toSecType (undef ined :: st ) ) 
(toLabel (undef ined: : lb) ) 
instance (STSecType stl 1, STSecType st2 1) 
=> STSecType (SSecPair stl st2) 1 where 
toSecType _ 

= SecPair (toSecType (undef ined :: st 1 ) ) 
(toSecType (undef ined :: st2 ) ) 
instance (STSecType stl 1, 

STSecType st2 1, STLabel lb 1) 
=> STSecType (SSecEither stl st2 lb) 1 where 
toSecType _ 

= SecEither (toSecType (undef ined :: st 1 ) ) 
(toSecType (undef ined :: st2 ) ) 
(toLabel (undef ined :: lb) ) 

Functions toLabel and toSecType return security la- 
bels and security types based on singleton types, respec- 
tively. 

Having our encoding ready, we introduce references as 
values of the data type: data Ref st a = Ref st 
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(IORef a), where (IORef a) is the type for refer- 
ences in Haskell and st is a singleton type encoding the 
security type for its content. At this point, we are in con- 
ditions to extend the function buildSecType, used by 
lower A, to build output security types: 

instance (Lattice 1, STSecType st 1) 

=> BuildSecType SecType 1 (SRef st a) where 
buildSecType 1 _ 

= (SecRef (toSecType (undef ined : : st ) ) 1) 

Observe how buildSecType calls toSecType to build 
the security type for the content of the reference by passing 
an undefined value of singleton type st. The subtyping in- 
variant is now preserved by 1 owe r A. In fact, this technique 
can be used to preserve any subtyping invariant required in 
the library. 

4.4 Reference Manipulation 

Li and Zdancewic's library uses the underlying arrow 
(->) to perform computations. However, we need to mod- 
ify that in order to include side-effects produced by refer- 
ences. The following data type defines the underlying arrow 
used in our library: data ArrowRef a b = a -> 
10 b. Underlying computations can therefore take an ar- 
gument of type a and return a value of type (10 b), which 
probably produces some side-effects related to references. 

Three primitives are respectively provided to create, 
read, and write references: createRefA, readRefA, 
and writeRefA. Basically, these functions lift the tra- 
ditional Haskell operations to manipulate references into 
FlowArrowRef , but performing some checking related 
to information-flow security (see Section 4.5). However, 
from a programmer's point of view, they look similar to 
any primitives that deal with references. For instance, 
createRefA has the following signature: 

createRefA : : (Lattice 1, STSecType st 1, 
BuildSecType 1 a) => 
st -> 1 -> FlowArrowRef 1 ArrowRef a (Ref st a) 

where singleton type st encodes the security type for 
the content of the reference, and 1 is the security level 
of the reference as a value. Observe that ArrowRef 
is used for the underlying computation. As an exam- 
ple, (createRefA (VSecLabel VHigh) LOW) re- 
turns a computation that creates a public reference to a se- 
cret value received as argument. This is the only primi- 
tive where programmers must use singleton types and where 
the library exploits the correspondence between values and 
types. Because of that, it could be possible to remove the 
argument st from createRefA to make its type signa- 
ture simpler. However, by doing that, programmers would 
need to explicitly specify the type for every occurrences 
of createRefA with their corresponding (STSecType 
st 1) and (Ref st a) . 



e(s\) -> ti e(s\) -> £ 2 



e((either s\ s\f) -> £ e(only£) I 



e(s L ref £ ) -> £ 

Figure 14. Definition for Function < 

4.5 Typing Rules for Reference Primitives 

Pottier and Simonet present a type-based information 
flow analysis for CoreML equipped with references, ex- 
ceptions and let-polymorphism [18]. Particularly, their type 
system is constraint-based and uses effects to deal with ref- 
erences. We restate some of their ideas in the framework 
of our library. More precisely, we adapt our encoded type- 
checker to include effects and consequently involve refer- 
ences. 

We enhance the typing judgement introduced in Section 
3.2 as follows: pc ,C h / : t\ \ s\ — > t%\ s^, where the 
new parameter, pc, is a lower bound on the security level of 
the memory cell that is written. In Figure 15, we show how 
typing rules for pure, sequential, and branching computa- 
tions are rewritten using this new parameter. Typing rules 
for other combinators are adapted similarly. Rule (PURE) 
produces no side-effects and therefore it imposes no lower 
bounds in pc. Rule (SEQ) takes the meet of the lower 
bounds for side-effects as the new pc. Rule (CHOICE) es- 
sentially requires that the branching computation does not 
produce side-effects or results that are below the guard of 
the branch, which has type either n r 3 . These require- 
ments are enforced by (eithers^ s^) 1 [pc\ l~l pc2) and 
(either s\ s\) e <e{] (s\Us\, £)), respectively. As defined 
in Simonet and Pottier's work, constraint s L <£ imposes I as 
an upper bound for every security label in s L . Function e de- 
termines the security level of a given value (see Figure 14). 
Operator \ lifts security labels that are below certain secu- 
rity level, but not violating subtyping invariants (see Figure 
16). 

Typing rules for references are introduced in Figure 17. 
Singleton type s L encodes the security type s L and is gen- 
erated by the value (s L )„. Rule (CREATE) requires that 
the singleton type passed as argument matches the input se- 
curity type. Otherwise, programmers could introduce in- 
consistencies in the type-checking process. The side-effect 
produced by creation of references is allocation of memory. 
Therefore, the pc is related with the security level of the 
content of the created reference (e(s\)). Rule (READ) lifts 
security labels in the output security type considering the 
security level of the reference (t (s\,£)). Rule (WRITE) 
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(PURE)- 



f ■■ n 



T2 



(SEQ)- 



(CHOICE) 



T, 0 h pure / : n | s\ -> r 2 \ only i 

pcuCuhfi : n 1 s\ -> T 2 1 s\ pc 2 ,C 2 h h : r 2 | s| -> r 4 | 

PCI npC2,Cl U C 2 U {Sj E Ss} I" /l »> / 2 : Ti Si — » T4 | S4 

pci, Ci h /1 : n I s\ t 2 I s\ pc 2 , C 2 , h / 2 : r 3 | s| r 2 | s| 



pci npc 2 , Ci U C 2 U C 3 h /1 HI / 2 : //ow 
/Zoto = either n r 3 | (either Si 4)' ~> t 2 | T (s 2 U 84,^) 
C 3 = {(eithers^ s|) £ -« (pci n P c 2 ), (either s\ s\f + e(| (s| U s\,£))} 

Figure 15. Typing rules for pure, sequential composition, and choice combinators 

ii e 12 e 2 \z ii £1 e £ 2 c £1 



T 4- 



T £1 £2 -> £1 

- «s T «a< 



T (s L ref £l )£ 2 



T (s L ref £l )fe s L ref' ;i 



„L 
S 4 



£l E £2 T ^ <2 4 T 4 <?2 



S 4 



<a C <i T 4 <a -» s| T s 2 



„L 
S 4 



T (either s\ s^f 1 £ 2 (either s| s|)^ 2 

£1 E £2 £ 2 c £1 



T (either s\ s\f l £2 (either s| si")" 1 T (only£i)£ 2 only | (only£i)£ 2 only h 

Figure 16. Definition for Function f 



imposes the constraint £<is L . Similarly to Simonet and Pot- 
tier's work, constraint I < s L requires s L to have security 
level £ or greater, and is used to record a potential informa- 
tion flow. 

We modify the implementation of the type-system in 
our library to include effects. Consequently, data type 
FlowArrowRef is extended with a new field called pc to 
represent lower bounds for side-effects as explained above. 
Data type Constraint is also extended to involve oper- 
ators < and M. Moreover, we add unification mechanisms 
inside of arrow combinators to pass information about secu- 
rity types when needed. As a consequence, a few security 
annotations need to be provided by programmers. Li and 
Zdancewic's library does not need this feature since their 
security types are very simple. One of the interesting aspect 
of implementing unification inside of arrows is the genera- 
tion of fresh names. Our library generates fresh names by 
applying renaming functions when arrow combinators are 
applied, but we omit the details here due to lack of space. 

4.6 Filtering References 

References introduce the possibility of having shared re- 
sources in programs. In Section 3.4, the filtering mechanism 
replaces some pieces of information with undefined. 
However, it is not a good idea to replace the content of some 
reference with u n de f i n e d since it might be used by other 



parts (or threads) in the program. We still need to restrict 
the access to that content somehow. In order to do that, we 
introduce projection functions for each reference handled 
by the library. Projection functions are basically functions 
that return values less informative than their arguments. The 
concept of projection functions has been indirectly used 
in semantic models for information-flow security [10, 26]. 
The instance for references of the method removeData 
creates projection functions that, when applied to the con- 
tents of their associated references, return values where 
some information higher than some security level is re- 
placed by undefined. However, the content of the ref- 
erence itself is not modified. Observe that the filtering prin- 
ciple applied by projection functions and removeData is 
the same. Combinator readRef A is also modified to re- 
turn the content of the reference by firstly passing it through 
its corresponding projection function. Due to lack of space, 
we omit the implementation of these ideas here. 

5 Information Flow in a Concurrent Setting 

Concurrency introduces new covert channels, or unin- 
tended ways, to leak secret information to an attacker. As a 
consequence, the traditional techniques to enforce informa- 
tion flow policies in sequential programs are not sufficient 
for multithreaded languages [32]. One particularly danger- 
ous covert channel is called internal timing. It allows to 
leak information when secrets affect the timing behavior of 
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(CREATE)- 



e(si),0 h createRefA (si)„ t : r \ s\ -> r ref \ s\ ref* 



(READ)- 



T, 0 h readRef A : r ref \ s\ ref* -> r | | 0 



(W RITE)- 



e(s L ), {£ <l s L } h writeRef A : (r re/, r) | (s L ref/, s L ) — ► () | _L 

Figure 17. Typing rules for reference primitives 



a thread, which via the scheduler, affects the order in which 
public computations occur. Consider the following two im- 
perative programs running in two different threads: 

ti : (if h > 0 then skip(120) else skip(l)); 1 := 1 
t 2 : skip(60); 1 := 0 (2) 

Variables h and I store secret and public information, re- 
spectively. Assume skip(n) executes n consecutive skip 
commands. Notice that both t\ and i 2 are secure in isola- 
tion under the notion of noninterference [25]. However, by 
running them in parallel, it is possible to leak information 
about h. To illustrate that, we assume an scheduler with 
time slice of 80 steps that always starts by running t\. On 
one hand, if h > 0, t\ will run for 80 steps, and while being 
running skip(120), t 2 is scheduled and run until comple- 
tion. Then, the control is given again to t\, which completes 
its execution. The final value of 1 is 1 . On the other hand, if 
h. < 0, t\ finishes first its execution. After that, i 2 is sched- 
uled and run until completion. In this case, the final value 
of 1 is 0. An attacker can, therefore, deduce if h > 0 (or 
not) by observing the final value of 1. Different from the ex- 
ternal timing covert channel, the attacker does not need to 
observe the actual execution time of a program in order to 
deduce some secret information. Moreover, internal timing 
leaks can also be magnified via loops, where each iteration 
of the loop can leak one bit of the secret. Hence, entire 
secret values can be leaked. 

There are several existing approaches to tackling inter- 
nal timing flows. Several works by Volpano and Smith 
[32, 35, 30, 31] propose a special primitive called protect. 
By definition, protect(c) takes one atomic step in the 
semantics with the effect of executing c to the end. In- 
ternal timing leaks are removed if every computation that 
branches on secrets is wrapped by protect() commands. 
However, implementing protect imposes a major chal- 
lenge [27, 23, 20] (except for cooperative schedulers [21]). 
These proposals rely on the modification of the run-time 
environment or the assumption of randomized schedulers, 
which are rarely found in practice. Russo et al. [19] propose 
a transformation to close internal timing channels that does 
not require the modification of the run-time environment. 
The transformation works for programs that run under a 
wide class of round-robin schedulers and only rejects those 
ones that have symptoms of illegal flows inherent from se- 



quential settings. Boudol and Castellani [2, 3] propose type 
systems for languages that do not rely on the protect prim- 
itive. However, they reject programs with assignments to 
low variables after some computation that branches on se- 
crets. Internal timing problem can also be solved by con- 
sidering external timing. Definitions related to external tim- 
ing involve stronger attackers. As expected, an stronger at- 
tacker model imposes more restriction on programs. For 
instance, loops branching on secrets are disallowed. There 
are several works on that direction [1, 27, 23, 24, 11]. 
Zdancewic and Myers [37] prevent internal timing leaks by 
disallowing races on public data. However, their approach 
rejects innocent secure programs like I := 0 || I := 1 where 
I is a public variable. Recently, Huisman et al. [9] improved 
Zdancewic and Myers' work by using logic -based char- 
acterizations and well known model checking techniques. 
Several proposals have been explored in process-calculus 
settings [6, 4, 22, 7, 17], but without considering the impact 
of scheduling. 

The referred works above have neglected to consider im- 
plementing case studies where the proposed enforcement 
mechanisms are applied. This work presents, to the best of 
our knowledge, the first concrete implementation of a case 
study that consider information-flow policies in presence of 
concurrency. 

6 Closing Internal Timing Channels 

We incorporate a run-time mechanism to close internal 
timing covert channels in our library. We base our ap- 
proach in a combination of ideas taken from the literature. 
On one hand, Russo and Sabelfeld [21] show how to im- 
plement protectQ for cooperative schedulers. Essentially, 
their work states that threads must not yield control inside 
of computations that branch on secrets. Russo et al. [19], 
on the other hand, express that a class of round-robin sched- 
ulers does not suffer from leaks due to dynamic thread cre- 
ation. As a consequence, creation of threads can be allowed 
at any point in programs. By mixing these two ideas, we 
modify the underlying arrow combinators in order to imple- 
ment a cooperative round-robin scheduler and to guarantee 
that computations branching on secrets do not yield con- 
trol when running. In this way, internal timing leaks are re- 
moved from programs and a flexible treatment for dynamic 
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thread creation is also obtained. In fact, the introduced mod- 
ifications are completely independent to the encoded type 
system described in Section 3 and 4. 

Cooperative schedulers are based on yielding control 
when programs indicate that. On the other hand, programs 
are written using arrow combinators, which can be seen as a 
kind of building blocks. In our library, simple arrow combi- 
nators yield control after finishing their execution if they are 
not part of computations that branch on secrets. Example 
of such combinators are pure, createRef, readRef, 
and writeRef. Computations branching on secrets do not 
yield control regardless how many building blocks compose 
them. As result, simple arrow combinators and computa- 
tions that branch on secrets are atomic computational units 
involved in interleavings. The round-robin scheduler is ob- 
tained by yielding control in a particular way. 

Concurrency is introduced in our implementation by 
importing the Haskell module Control . Concurrent 
[28, 33] . This module provides dynamic thread cre- 
ation and pre-emptive concurrency. Since threads can be 
scheduled anytime, some synchronization is needed to re- 
strict their execution as round-robin. Software transac- 
tional memory(STM) [5] provides easy-to-reason and sim- 
ple primitives to do that. We could have chosen more stan- 
dard primitives like semaphores or MVar [28]. However, 
the obtained code would have been more complicated. 

We start introducing information about scheduling on the 
underlying arrow ArrowRef : 

data RRobin a = RRobin 

{ data : : a, iD : : Threadld, 

queue :: TVar [Threadld], blocks :: Int } 

data ArrowRef a b 

= AR ( (RRobin a) -> 10 (RRobin b) ) 

Data type (RRobin a) stores information related to 
scheduling in the input and output values of arrows. Field 
data stores the input data for the arrow. Field iD stores 
the thread identification number where the arrow compu- 
tation is executed. Field queue stores a round-robin list 
of threads identifiers and its access is protected by a mutex 
(TVar [Threadld] ). The list is updated when creation 
or termination of threads occur. Field blocks indicates if 
the thread executing the arrow computation must wait for its 
turn to run and then, when finishing, yields the control to an- 
other thread. This field plays an essential role to guarantee 
atomic execution of computations that branch on secrets. 

We introduce two new combinators in the underlying 
arrow: waitForYield and yieldControl. Essen- 
tially, these combinators are responsible for implement- 
ing a round-robin scheduler. Combinator waitForYield 
blocks until the content of the head of the round-robin 
queue (TVar [Threadld]) is the same as the thread 
identification (iD) running this combinator. Combina- 
tor yieldControl removes the head of the round-robin 



waitTurn :: RRobin a -> 10 () 

waitTurn sch = if (blocks sch) > 0 then return () 
else atomically ( 

do q <- readTVar (queue sch) 
if head q /= (iD sch) 
then retry 
else return ( ) ) 

waitForYield : : ArrowRef a a 
waitForYield = AR (\sch -> do waitTurn sch 

return sch) 

nextTurn :: RRobin a -> 10 () 
nextTurn sch 

= if (blocks sch) > 0 then return () 
else atomically ( 

do q <- readTVar (queue sch) 
writeTVar (queue sch) 

( (tail q) ++ [head q] ) 

return () ) 

yieldControl : : ArrowRef a a 
yieldControl = AR (\sch -> do nextTurn sch 

return sch) 



Figure 18. Primitives for yielding control 

beginAtomic : : ArrowRef a a 
beginAtomic 

= waitForYield >>> 

AR (\sch -> return sch (blocks = 

( (blocks sch) +1) ) ) 

endAtomic : : ArrowRef a a 
endAtomic 

= AR (\sch -> return sch (blocks = 

( (blocks sch) -1) ) ) 

>>> yieldControl 



Figure 19. Primitives for atomicity 

queue and put it as the last element. Both combinators 
have no computational effects if the field blocks is dif- 
ferent from zero. The implementation of these combinators 
is shown in Figure 18. Function atomically guarantees 
mutual exclusion access to the round-robin queue. Function 
retry blocks the thread until queue changes its value. 
When this happens, it resumes its execution from the first 
command wrapped by atomically. It is important to 
remark that combinators in the underlying arrow are not ac- 
cessible for users of the library. 

Simple arrow combinators include now 
waitForYield and yieldControl before and after 
finishing their computations, respectively. Nevertheless, 
combinators related with branches are threaded differently. 
Computations that branch on secrets must not yield control 
until finishing their execution. Branching combinators, like 
(HI), can be applied to arrow computations that involve 
yieldControl in their bodies. As a consequence, 
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pc,Ch/ : n | s\ -> r 2 | s| 
pc, C h f orkRef / : Ti | Si ->■ () | _L 

Figure 20. Typing rule for f orkRef 

when the guard of the branch involves some secrets, these 
combinators must no yield control to other threads. We 
introduce two more combinators to the underlying arrow: 
beginAtomic and endAtomic. When placed like 
beginAtomic >>> f >>> endAtomic, they leave 
without any effect the combinators waitForYield and 
yieldControl appearing in f. Therefore, program 
f executes until completion without yielding control to 
other threads. We then modify the implementation of 
combinators related with branchings in order to include 
beginAtomic and endAtomic when the condition 
of the branch depends on secrets. The Implementation 
of beginAtomic and endAtomic is given in Figure 
19. Observe that beginAtomic and endAtomic 
count how many computations branching on secret are 
nested. Combinators waitForYield, yieldControl, 
beginAtomic and endAtomic need to be pairwise to 
properly work. 

Dynamic thread creation is introduced by the new arrow 
combinator f orkRef . It takes a computation as argument 
and spawns it in a new thread with an exception handler. If 
the new thread raises an exception, the handler forces all the 
program to finish, reducing the bandwidth of leakings due to 
no termination. The typing rule for f orkRef is shown in 
Figure 20. Observe that the returned value of / is discarded 
since / will be run in another thread. 

7 Case Study: Online Shopping 

In order to evaluate the flexibility of the arrow combi- 
nators and techniques proposed in Sections 3, 4, and 6, 
we implemented a case study of an online shopping server. 
Basically, the server processes transactions related to buy- 
ing products. It receives information from the network 
and spawn different threads to perform purchases for each 
client. For simplicity, we assume that there is only one prod- 
uct to buy and that the only information provided by clients 
are their names, billing addresses, and credit card numbers 
composed of 16 digits. We also assume that there are secu- 
rity levels HIGH and LOW for secret and public information, 
respectively. Our library guarantees, in this example, that 
the confidentiality of credit card numbers is preserved. 

The server program consists of three components: 
protectData, purchase, and showPurchase. 
Component protectData receives information from 
clients and determines that credit card numbers are the 
only secrets in the system. The implementation of 
protectData consists of a few lines of code that ap- 



ply combinator tag to its input. We consider this com- 
ponent as part of the trusted computing based. Component 
purchase simulates buying products. Moreover, it copies 
the client credit card number and the rest of his/her infor- 
mation into two different databases, respectively. We sim- 
ulate the access to these databases with references to dif- 
ferent lists of data. Component showPurchase retrieves 
information from the database with public information and 
shows it on the screen (a public channel). 

The online shopping server can be modified to execute 
malicious code that exploits internal timing covert channels. 
An attack similar to (2) can be implemented if no counter- 
measures are taken. However, such an attack only reveals 
one bit of the secret. In order for the attacker to obtain com- 
plete credit card numbers, it is necessary to magnify the 
attack by introducing a loop. Then, one bit of the secret 
is leaked in each iteration of the loop. The implementa- 
tion of this attack reveals a credit card number in about two 
minutes 2 . Surprisingly, it was quite straightforward to leak 
the sixteen digits of a credit card number even though we 
have no information about the run-time environment. This 
shows how feasible and dangerous are internal timing leaks 
in practice. 

Our malicious code concatenates credit card numbers 
after the billing addresses of clients. Thus, credit card 
numbers can be displayed on the screen by just invoking 
showPurchase. To illustrate that, we consider a client 
with the credit card number 9999999999999999. We 
run the attack several times obtaining different leaked credit 
card numbers (see Figure 21). These numbers differ in at 
most three bits from the binary representation of the se- 
cret. This imprecision comes from the lack of knowledge 
about the run-time environment, in particular, the lack of 
knowledge about scheduler policies. Scheduler policies are 
important for an internal timing attack to succeed. Nev- 
ertheless, by repeatedly running the attack and taking the 
most frequent boolean values in each position, it is possible 
to obtain the value of the secret with very high confidence. 
Observe that the secret and the inferred secret are the same 
in Figure 2 1 . 

We repeatedly ran the malicious code mentioned above 
but with the countermeasures described in Section 6. In this 
opportunity, the leaked credit card number was always 0. In 
other words, the attack did not succeed. There is an obvious 
overhead introduced by restricting the scheduler in the run- 
time environment to behave like a round-robin one. How- 
ever, this is acceptable since only small parts of a system 
need to manipulate secrets and therefore be written using 
our library. 



2 Every experiment was run on a laptop Pentium M 1.5 GHz and 512 
MB RAM. 
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Secret: 
Run No. 



100011100001101111001001101111110000001111111111111111 

Leaked credit card number Time(Sec) 



1 101011111001111111111011101111110000011111111111111111 27 

2 110011100001101111011101101111010000001111111111111111 27 

3 101011100001101111101001101111110000001111111111111111 28 

4 100011100101101111001001101111110000001111111111111011 28 

5 100011100001101111001001101111110100001111111111111111 29 



Inferred Secret: 10001 1 100001 101 1 1 1001001 101 1 1 1 1 10000001 111111111111111 

Figure 21. Results produced by the malicious code 



8 Conclusions 

We have presented an extension to Li and Zdancewic's 
library to consider secure programs with reference manipu- 
lation and concurrency. Moreover, a case study has been 
implemented to evaluate the techniques proposed in this 
work. It reveals that internal-timing leaks are feasible and 
dangerous in practice and shows how our library properly 
repairs them. To the best of our knowledge, this is the 
first tool that supports information-flow security and con- 
currency, and the first case study implemented that involves 
concurrent programs and information-flow policies. 

The extension to the library consists on two different 
parts. On one hand, we include reference manipulation by 
considering richer security types than those appearing in Li 
and Zdancewic's work. This consideration allows us to de- 
scribe a more precise analysis for information-flow security 
than that obtained by just considering single security labels 
as security types. In order to get such analysis, we combine 
several ideas from the literature in our implementation: sin- 
gleton types, type-classes in Haskell, and projection func- 
tions. On the other hand, supporting concurrency requires 
dealing with internal-timing attacks. The extension includes 
a mechanism to close internal-timing covert channels and 
provides a flexible treatment for dynamic thread creation. 
Therefore, it is not necessary to modify the run-time envi- 
ronment to obtain secure programs. These achievements are 
also result of combining several ideas from the literature: 
round-robin cooperative schedulers and software transac- 
tional memories. Similarly to Li and Zdancewic's work, the 
technical development in this paper is informal, although 
we have implemented it in Haskell. The type system en- 
coded in FlowArrowRef can be mainly justified by fol- 
lowing standard techniques to prove non-interference prop- 
erties [36, 18]. The implementation of the library and the 
case study is publicly available in [34]. 
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